Як видалити Реле

MEV-Boost — це допоміжний автомобіль для видобутку MEV на поточній біржі ETH, яка значною мірою покладається на централізованого учасника під назвою Реле. Ми пропонуємо альтернативну архітектуру, яка забезпечує прямий, криптографічно приватний зв'язок між розробниками та ініціаторами. Ця архітектура базується на новій неінтерактивній формі "тихого" порогового шифрування, яка може використовувати існуючі пари ключів BLSСекретний.

Взаємодопомогаючи комітету довідок вони формують секретний ключ для розшифрування; як тільки досягнуто необхідного порогу, Блок може бути розшифрований.

Наша конструкція вирішує проблеми конфіденційності між будівельниками та пропонентами, але сама по собі не гарантує ефективність Блок. Вона може поєднуватися з іншими механізмами, щоб повністю реплікувати функції Реле, включаючи конфіденційність та ефективність Блок. Наприклад, це може бути досягнуто за допомогою довірчих виконавчих середовищ (TEE) або доказів знань (ZK), або за допомогою шифрування економічного механізму для забезпечення будівельників.

Шляхом усунення потреби в приватності будівничого Реле та забезпечення ефективності Блок ми сподіваємося зменшити затримку, підвищити децентралізацію та опору цензурі Ethereum.

Роль MEV-Boost та Реле

MEV-Boost - це протокол проміжне, який діє як проміжне між Блок будівельником та пропонуючим, забезпечуючи дві гарантії: головна роль Реле - це забезпечення двох головних функцій:

Конфіденційність будівництва: Реле гарантує, що пропонувач не може бачити вміст Блоку і не може вкрасти знайдене будівництвом MEV.
Забезпечення безпеки пропозиції: Реле гарантує, що будівельники виплачують пропозиції вартість, вказану в їх пропозиції, та забезпечують, що Блок є дійсним (наприклад, всі угоди оплачують внутрішню газову плату).

Однак, залежність від Реле призводить до значної централізації. Близько 90% блоків ETH мережі передаються через лише кілька Реле. Це приносить кілька ризиків:

Децентралізація: розробники можуть підвищити ефективність затримки шляхом спільного розгортання з Реле, а не відображати географічний розподіл пропонентів. Це безпосередньо підриває географічну децентралізацію та здатність до опірності цензурі, яку ми могли отримати від широкого географічного розподілу мережі валідаторів.
Дохід: середня затримка з кінця в кінець обробки блоків Реле становить приблизно 5-20 мілісекунд. Крім того, існує затримка у комунікації між будівельником та пропонувачем. Пропускання Реле знизить затримку, зменшить ризик виконання міждоменних операцій (наприклад, CEX/DEX) та в кінцевому підсилить MEV винагороду для пропонувача.

TEE-Boost

Один з основних пропозицій щодо заміни Реле - “TEE-Boost”, який базується на довіреному середовищі виконання (TEEs). Слід зауважити, що TEE не є ядром нашої пропозиції; використання TEE-Boost як навчального прикладу для проблем, які ми прагнемо вирішити, є дуже корисним.

Конкретно кажучи, TEE-Boost вимагає від будівельників використовувати TEE для створення доказів, які показують чесність їх пропозицій та дійсність Блоку, не розкриваючи фактичного вмісту Блоку пропонентам. Пропоненти можуть перевірити ці докази на звичайному обладнанні, не запускаючи TEE самостійно.

Проте, TEE-Boost має проблеми з доступністю даних: конструктори діляться лише з пропонентами доказами TEE та Блок-хедером, а не фактичним вмістом Блоку [SUP] [посилання][1], а також можуть вибрати не випускати вміст Блок після підписання пропонента (наприклад, якщо умови на ринку негативно змінилися). Пропозиції щодо вирішення цієї проблеми доступності даних включають:

TEE-збереження: TEE-збереження отримує Блок від будівельника перед підписанням пропозиції та вивільняє цей Блок після перегляду підписувальної головки.

Шара доступності даних: розробник публікує зашифроване навантаження блоку на рівні доступності даних (DA).

Ці обидва методи мають свої недоліки. Рішення зберігання TEE-камери реплікує централізовану затримку динаміки SUP[2]. Якщо використовувати зовнішній шар DA, це призведе до введення додаткових припущень щодо протоколу та затримок, пов'язаних з цим зовнішнім протоколом (які також можуть бути небажаними).

Теоретично, якщо пропонувач також може отримати доступ до TEE, будівельник може зашифрувати Блок до TEE, який пропонувач виконує. TEE пропонувача розшифрує Блок тільки після підписання. Однак ми вважаємо, що TEE-Boost не врахувала цей дизайн, оскільки це вимагатиме від пропонувачів (валідаторів) виконання TEE. Ми хочемо, щоб валідатори могли працювати на звичайному обладнанні. [↩] (https://www.paradigm.xyz/2024/10/removing-the-relays#fn-ref-TEE-Boost)
Якщо пропонувальник самостійно розгорне TEE-зберігання як бічний рух разом з вузлами валідаторів, то можна уникнути затримки в русі

Однак ми також не хочемо, щоб валідатори запускали TEE. ↩

Криптографія з пороговим доступом для забезпечення конфіденційності будівництва

Ми запропонували елегантне рішення для вирішення проблеми доступності даних TEE-Boost: застосування порогового шифрування до валідаційної комісії. Конкретно, будівельник шифрує Блок пороговим шифруванням до валідаційної комісії, визначеної у вказаному вікні. Як тільки буде зібрано достатньо підтверджень, Блок можна розшифрувати та використовувати.

Основною використовуваною технологією є беззвучне порогове шифрування. Ця криптографічна технологія дозволяє проводити порогове шифрування, не потребуючи попередньої побудови необхідної інтерактивної розподіленої установки Секретний ключ Генерації (DKG). Натомість, спільний Відкритий ключ визначається на основі вже існуючих Відкритий ключ BLS та деяких "натяків" (подальше обговорення) за допомогою детермінованого обчислення, яке здійснюють валідатори.

Це реалізує пряму одноразову комунікацію між будівельником та валідаторами з криптографічною конфіденційністю. Валідаторам не потрібно запускати TEE або керувати будь-яким новим матеріалом Секретного ключа.

Механізм:

Конструктор конструює блок та шифрує його до комісії з підтвердження.

Будівельник побудував TEE доказ, щоб довести комісії перевірки три аспекти: пропозиція є чесною, Блок є дійсним і шифрування є правильним.

Будівельники передають пропонентам зашифровані блоки та докази TEE (включаючи вартість) з встановленим порогом. [3]

Пропонент підписує переможця конструктора блоку і розповсюджує це пропозицію серед набору перевіряючих.

Коли комітет перевірки, який призначений у визначеному співвідношенні (наприклад, n/2 або 2n/3), автентифікує Блок, він розшифрується.

Після розшифрування Блок буде нормально підтверджено.

Вплив потреби в пропускній здатності від пропонента потребує дослідження. Пропонент з низькою пропускною здатністю може обмежити свої потреби шляхом доказу валідації перед тілом Блок або використовуючи інші евристичні фільтри та технології розумного завантаження. Це відкрите питання, але вирішення його, схоже, не є складнішим, ніж звичайне поширення спаму в пулі пам'яті.

Правила

Поведінка

Характеристики продуктивності шифрування з беззвучним порогом є досить перевагами. Тут n - це максимальний розмір комітету, який ми хочемо підтримувати, t - це поріг розшифрування.

шифрування та часткове розшифрування виконуються за постійний час. Використання простої реалізації, шифрування займає менше 7 мілісекунд, і може бути паралельною. Часткове розшифрування займає менше 1 мілісекунди.

Розмір шифротексту більший за розмір відкритого тексту у 768 байтів, це постійний додатковий фактор (для будь-якого n та t).

Дешифрування часткової агрегації (тобто розшифрування) залежить від розміру комітету. Коли n=1024, проста реалізація займає менше 200 мілісекунд. Ми очікуємо, що при n=128 (розмір комітету аутентифікації на кожному інтервалі) цей час зменшиться в 10 разів, і реалізацію можна ще додатково оптимізувати.

Важливою є шифрування часу, який є ключовим показником продуктивності порівняно з затримкою реле. Це те, що будівельник повинен розраховувати на "критичному шляху" побудови блоку. Цей час нижче за затримку обробки блоку існуючого реле і уникне багаторазового комунікації.

Публікація даних

Беззвучний поріг шифрування не є повністю безкоштовним. Він дійсно потребує спільного посилання рядка у формі: (g, gτ, gτ², …, gτⁿ⁻ᵗ), схожого на вміст, що використовується для схеми зобов'язання поліномів KZG.

Крім того, кожен валідатор з відкритим ключем BLS у форматі g⁽ˢᵏ⁾ публікує групу елементів, яку ми називаємо "підказками": (g⁽ˢᵏ⁾⋅τ, ..., g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). Ці підказки потрібні лише при агрегації відкритого ключа та розшифруванні шифротексту. Шифрування використовує лише агрегований відкритий ключ фіксованого розміру.

На момент написання цієї статті було близько 1 мільйона валідаторів. Якщо ми встановимо n=128 і t=n/2, кожен валідатор має опублікувати приблизно 3 КБ підказок. Таким чином, для зберігання всіх підказок валідаторів потрібно 3 ГБ простору.

З активацією MaxEB цей вимога може значно Падіння, MaxEB дозволяє контролювати більше 32 ETH валідатори володіти більший баланс під одним Секретний ключ (замість розподілу його на кілька депозитів по 32 ETH). Зменшення набору валідаторів, що буде досягнуто, ще обговорюється. Ми можемо зменшити до близько 1 ГБ.

Нарешті, враховуючи майбутні зміни в архітектурі Ethereum згідно з принципами Консенсусу (наприклад, подальше зменшення розміру набору валідаторів або заміна фінального конвеєра), можливо, зменшиться розмір тіпсу, який потрібно зберігати.

Енергія

ETH Square хоче залишатися онлайн, незважаючи на несприятливі умови мережі. Одна з проблем схеми полягає в тому, що через те, що комісія зазначеного коефіцієнта знаходиться в автономному режимі, може бути Блок, який неможливо розшифрувати.

Одним з рішень є дозвіл будівельникам визначати прийнятний відсоток комітету (t) для розшифрування. Існує компроміс між конфіденційністю (можливість розшифрування та можливість крадіжки MEV) та можливістю встановлення порогу комітету. Для будівельників найкращим способом максимізувати прибуток є включення їх Блоків у ланцюг, а не форк. Тому вони повинні знайти оптимальну настройку порогу.[4]

Крім того, використання цієї шифрування має бути добровільним вибором. У непридатних умовах мережі, якщо немає жодної прийнятної комісії, яка може продовжувати працювати в режимі онлайн, пропоненти та розробники можуть повернутися до використання Реле, самостійної будівлі або інших механізмів, які вибираються в залежності від непридатних умов.

Конкретно, очікувана вартість форкнутого Блоку для конструктора є від'ємною (вони не отримують прибутку з неї), а очікувана вартість розпакованого Блоку є дуже від'ємною. Якщо дати конструктору вибір t в діапазоні [0, 128], вони мають мотивацію обрати досить високе значення t, щоб зменшити ризик розпаковки та збільшити ймовірність задоволення (принаймні t членів комітету в LINE). При нормальних умовах мережі деякі Блоки можуть бути форкнуті, але ми зауважуємо, що це вже сталося в гральному часі, і життєздатність ланцюжка все ще є прийнятною.

Недоступний блок

Крім того, комітет може бути онлайн, але конструктор може створити таку ситуацію, коли Блок не може бути розшифрований або стає недійсним (наприклад, використовуючи шахрайське підтвердження).

З протоколу можна видалити ці форки. Більш широка група валідаторів просто не зможе підтвердити такі блоки або будь-які посилання на них. Найкращим шляхом вирішення цієї помилки може бути свідомість клієнта Консенсус про цю можливість і здатність гарно збоювати. Це потребує подальших досліджень.

Структура ринку

Переможець будівельників знає вміст Блоку до досягнення порогового значення, що може створити невідповідну перевагу в наступний період. Однак комітет з доказами має діяти до завершення наступного періоду, а більшість вартості Блоку концентрується під час завершення періоду, тому вплив цієї переваги слід зменшити наскільки це можливо.

Чисто криптографічне підтвердження

З довгострокової перспективи, можливо, з'явиться шанс використати Доказ із нульовим розголошенням (ZK证明) замість TEE证明. Наразі швидкість ZK证明 занадто повільна, але прогрес в криптографії, програмному забезпеченні та спеціалізованому обладнанні (ASICs) можливо в кінцевому підсумку зробить генерацію ZK证明 в межах необхідної затримки прийнятною. Варто зазначити, що разом з Блок ZK证明 вже є ключовою частиною ETH坊 довгострокової стратегії.

Використовувати

З урахуванням поточного масштабу та темпів зростання мережі валідаторів ця схема, ймовірно, не варта обсягу даних, необхідних для публікації на L1. Однак Ethereum вже планує значно зменшити кількість валідаторів за допомогою MaxEB.

Найкращим способом може бути оновлення до Консенсусу до чи після MaxEB, щоб клієнт могли розпізнати можливість шифрування семантики Блоку та заохочувати валідатори публікувати підказки. Наприклад, після MaxEB можна вимагати від нових валідаторів публікації підказок, а старим валідаторам можна надати стимули для оновлення.

Як тільки достатня кількість валідаторів приймає цей механізм, будівники почнуть його використовувати, щоб забезпечити достатній розмір комітету (тобто, можливість забезпечення конфіденційності та дешифрування).

Якщо наш метод дійсно кращий за затримка у багатоскоковому пересиланні, то ринок, ймовірно, прийме його самостійно, без примусового використання протоколу або встановлення певних параметрів.

Основний принцип

Реле є одним з найважливіших централізованих джерел на Ethereum, що спричиняє появу можливостей оренди та спотворення географії протоколу Децентралізація. Нам потрібно видалити Реле і вважати це досить елегантним рішенням. Це потребує змін на рівні згоди, але валідатори не повинні надавати нове апаратне забезпечення або матеріали Секретний ключ.

Недолік полягає в тому, що це складні зміни на рівні згоди, а такий механізм (якщо він буде вибиратись у вигляді рекомендації) може бути прийнятий ринком, а може й ні. Однак багато потенційних змін у каналах MEV також стикаються з подібними питаннями прийняття і оптимізації доходів (наприклад, включаючи список). Крім того, у майбутньому можуть з'явитись інші випадки використання, які залежатимуть від того, щоб у валідаторів було інфраструктуру шифрування з порогом володіння.

Заява:

Ця стаття була взята з [paradigm], авторське право належить оригінальному автору [Charlie NoyesGuru, Vamsi Policharla], якщо у вас є заперечення щодо розміщення, зверніться до команди Gate Learn (https://www.gate.io/questionnaire/3967), команда якомога швидше вирішить проблему відповідно до відповідних процедур.
Відмова від відповідальності: погляди та думки, висловлені в цій статті, виражають лише особисту думку автора і не становлять жодних інвестиційних рекомендацій.
Інші мовні версії статей перекладає команда Gate Learn; без згадки Gate.io заборонено копіювати, поширювати або крадіжку перекладених статей.